Early web browsers for handling web documents, primarily documents written in HTML (Hypertext Markup Language), were designed to display and enable hyperlink functionality between content which mainly consisted of text and static images. However, with the rapid development of various Internet technologies, the handling of HTML and other web documents in web browsers has become much more complex and feature rich. For example, HTML documents now routinely include program code, for example in the form of JavaScript, JavaScript byte code, Java applets, Flash code, native executable code using systems such as PNaCI, and so forth.
It is also now routine for a single web browser session to handle multiple frames, each frame executing a different web document. When we refer to web browser frames, this includes various different ways in which such frames can be implemented, for example using multiple HTML iframes within a single window, HTML frames in separate windows, frame tags in XHTML, framesets and so forth. Also, when we refer to a frame we are including the root window of a browser session as a frame. Generally, other frames within the browser session will be children, grandchildren etc. of this root window frame.
Since each web document has an associated URI (Uniform Resource Indicator) which includes at least an Internet address from which the web document is obtained, each frame is also associated with the URI to which that frame is navigated. Sometimes, all of the frames in a web browser session might have the same Internet address or at least be from the same Internet domain, but often they will differ. A common example of differing Internet addresses or domains used within a single browser session would be in the situation of a mashup in which a parent frame includes content provided by a host server, and multiple child frames contain adverts delivered by a marketing server. In such a case, the Internet domains of the host server and the marketing server will typically be different. Other mashup examples are the inclusion of gadget frames served by third parties into a users customised home page provided by a host such as Yahoo, Google of Facebook, the provision of third party mapping functions into a business directory website, the provision of a banking payment or security check frame within a retail website, and so forth.
It is often desirable for the program code of one frame to communicate with the program code of another frame within the same browser session. However, there are also risks associated with this. For example, a malicious third party could provide program code in one frame (for example in an advertisement frame) which read a password or other sensitive data from another frame. To limit such risks, web browsers typically implement a same origin security policy which prevents, or limits the extent to which program code in one frame can communicate with another frame, if that frame is navigated to a document with a different origin.
The definition of “origin” of a document varies slightly between browsers and different implementations of same origin security policies, but typically may comprise at least the top and second level domain names and the Internet protocol type (HTTP, FTP etc.). Some browsers may consider URIs defining different third level domains, or defining different ports as being of different origins. Typically, two URIs can have different path parts mapping to a directory structure on the server, but be of the same origin.
Although mechanisms are available both formally within HTML standards and in other ways for providing cross origin communication between frames, the available technologies still make it challenging to implement, using a web browser, a graphical user interface (GUI) desktop environment which needs to use web documents from multiple origins to provide suitable integration between different tools or components of the desktop environment.
The invention seeks to address these and other problems of the related prior art.